Route computer and playwright calls directly to the VM - #157

QA’d commit 1b28d62 across sync and async clients.

• Browser-routing suite: 26 passed; PR CI is green.
• Focused experiments confirmed computer/batch, clipboard, screenshot, and Playwright calls route directly with the session JWT and without Authorization.
• process/*, fs/*, and telemetry/events retain API-origin routing and API authorization.
• Missing base_url, custom allowlists, and the empty-value kill switch behave correctly.
• Retry rewriting is idempotent and preserves request parameters.

Two non-blocking notes:

1. The computer prefix routes all computer/* endpoints, while the description and tests focus on screenshot/execute. Please consider one nested computer endpoint test.
2. A stale session JWT produces a direct-VM 401 with no automatic cache refresh or control-plane fallback. A follow-up could evict the route on 401/403 or document client.browsers.get(id) as the refresh path.

No blocking findings.

Cursor Bugbot has reviewed your changes using default effort and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit f525a24. Configure here.}

The stale-JWT fallback still has the cache invalidation race now covered in the Node and Go reviews.

_session_id_from_direct_vm_response() identifies the current cached route by base URL, then cache.delete(session_id) removes it without checking whether its JWT is the one that failed. If request A leaves with jwt-old, another request refreshes the same base URL to jwt-new, and A later returns 401, the fresh jwt-new route is deleted. I reproduced this against head 728330d: after replacing the cached route before processing the old 401, cache.get("sess-1") returns None.

The latest change correctly fixes the separate race where concurrent stale 401s stopped retrying after the first eviction, but it does not protect a newer cache entry from an older response.

Please make eviction conditional on the current route’s base URL and JWT matching the failed request, and add a regression test that refreshes the route while the stale request is in flight and asserts the fresh route survives. The existing routing suite passes, but does not cover this interleaving.

Verified at 111aa09. The race rgarcia flagged is fixed: delete_if_jwt refuses a mismatched JWT and still deletes a matching one, and with a refresh landing mid-flight the stale 401 leaves the fresh route alone (jwts sent to vm: ['jwt-STALE', 'jwt-FRESH'], fresh route intact). Suite green at 29, async path works.

Remaining issues are behavior drift from #173 (31517bb) and #167 (d5e0fc9). Same probes against all three heads:

                            Node          Go            Python
retries disabled            falls back    falls back    401, no fallback, stale route stays cached
budget spent by prior 500   falls back    falls back    401, no fallback, stale route stays cached
backoff added to fallback   none          none          ~390ms
fallback destination        control plane control plane whatever the cache says now

1. The fallback is gated on the retry budget, with three consequences. It lives in _should_retry, which the base client only consults when remaining_retries > 0. With max_retries=0 or with_options(max_retries=0) the 401 surfaces raw. The two eviction sites are _should_retry and _process_response, and neither runs on a terminal 401, so the dead route stays cached and never self-heals (three successive screenshots all raised AuthenticationError with the stale route still present). And because the gate is the budget rather than the config, a transient 500 earlier in the same call reproduces both at default settings, so this is not limited to users who disable retries. Node and Go avoid all of this by falling back inside a single attempt.

2. The fallback pays retry backoff, ~390ms measured from INITIAL_RETRY_DELAY plus jitter, against the 176ms this change is meant to save. Node and Go retry immediately.

3. The two SDK families promise different destinations. Under the race, Node and Go both go VM then control plane; here the retry re-runs _prepare_options and re-routes to the VM on the refreshed JWT. Arguably better since it keeps the latency win, but worth making a decision rather than a side effect of hook placement.

Coverage: no nested computer/* test (nothing in the file matches clipboard, and computer/clipboard/read and write are the only three-segment tails that route direct), and the three new fallback tests are sync-only.